Skip to main content

Deploying SmartBridge Full

SmartBridge Full includes additional capabilities for multi-factor authentication and simulated CAC certificates. While the installation is similar to the SmartBridge Core product, this version adds additional routing, infrastructure, and several more components to the cluster.

Like core, the installation of full is helm-based with additional configuration values as needed for multi-factor and simulated CACs.

This guide documents what infrastructure is required as pre-requisites, how to create and set the secret values SmartBridge needs, and how to configure the helm deployment.

System Architecture of SmartBridge Full​

Pre-requisites​

  • Kubernetes Cluster. Smartbridge works best in a minimum of 3-worker cluster and needs the equivalent of 6 vCPUs and 24 GiB of RAM total

    • Worker nodes will need permissions to read values from an AWS secret. The simplest method is to attach a policy to the AWS Role used by worker nodes (outlined below).

    • SmartBridge requires 2 Persistent Volume claims of approx 10 GiB each

  • Port 443 must be available on the cluster to serve mTLS traffic.

  • A TCP pass-through route to the cluster over port 443 for mTLS traffic. In AWS, this can be accomplished with a Network Load Balancer with TCP pass-through.

  • Permission to egress to the DISA website hosting CRLs (https://crl.gds.disa.mil/getcrlzip?ALL+CRL+ZIP)

  • Internal routes to access the SmartBridge APIs that support multi-factor and simulated CAC features. If you are running SmartBridge in the same kubernetes cluster as your system, these routes can be internal to the cluster. If SmartBridge is in its own cluster, ingress to the SmartBridge cluster must be permitted over port 31383.

  • A subdomain for CAC traffic, e.g. cac.yoursite.com, and a permitted route to the cluster over port 443.

    • NOTE: this may also be possible using a "slug", such as yoursite.com/cac. SmartBridge does not forward or re-route traffic, so the host system will need to route /cac traffic to SmartBridge and all other traffic to other appropriate locations).

  • Access to the key and certificate for the URL that will serve CAC authentication traffic (e.g. cac.yoursite.com)

  • Set-up of SmartBridge with credentials to the identity provider (a client_id and client_secret). These are used to authenticate the SmartBridge system when posting data about CAC authentications back to the identity provider.

  • If you set-up the SmartBridge demo site as a way to validate the correct functioning of SmartBridge, you will need an external URL, e.g. demo.yoursite.com, and a load balancer that routes traffic to the cluster over port 32000.

  • If you use an internal image repostory, you will need to load SmartBridge and 3rd party images into it, specifically:

    • SmartBridge CAC Interceptor
    • SmartBridge CRL Manager
    • SmartBridge Revocation Checker
      • SmartBridge Certificate Manager
      • SmartBridge MFA
    • ingress-nginx/controller:v1.7.0
    • minio:2021.5.27-debian-10-r0
    • minio-client:2021.5.26-debian-10-r0
    • hub.docker.com/stakatar/reloader:v0.0.94
    • hub.docker.com/redis:6.2.1-alpine

  • Helm - use helm to deploy SmartBridge

  • AWS CLI Access

  • Kubectl access to the cluster

Deploying SmartBridge​

  1. Create a secret in AWS Secrets Manager called smartbridge/{unique-name}. The script in helm/smartbridge/aws-secrets/create-secrets-template.sh uses the AWS CLI to create the secret with the appropriate values. Before running the script, you need:

    • An AWS authentication profile with permissions to create and/or update a secret in AWS Secrets Manager

    • A unique name for the smartbridge installation - this could be the EKS cluster name if deployed to its own cluster, or the name of an environment, e.g. "dev". The full secret name will be "smartbridge/{your-unique-name}

    • The client secret the SmartBridge app (plug-in) from MOTAR Studio.

    • The private key and public SSL certificate files for the domain that will handle CAC authentication

    • Registry credentials to allow SmartBridge to pull images from an image repository

  2. Create the following IAM policy in AWS and attach it to the role the Kubernetes workers use. This permits the SmartBridge containers access to the secret in AWS Secrets Manager. Use your account id and replace the "*" with the unique name you set for the secret above:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "Terraform",
            "Effect": "Allow",
            "Action": [
                "secretsmanager:GetSecretValue",
                "secretsmanager:DescribeSecret"
            ],
            "Resource": "arn:aws-us-gov:secretsmanager:us-gov-west-1:{YOUR-AWS-ACCOUNT-ID}:secret:smartbridge/*"
        }
    ]
}

  1. Use helm to deploy the SmartBridge nginx controller:

    • Navigate to the nginx deployment folder under helm/nginx

    • Create the kubernetes namespace with kubectl create namespace sb-ingress-nginx

    • Create a kubernetes secret for the truststore (Note: the truststore itself contains nothing secret, but the TLS secret type was the best way to manage the truststore). Run kubectl apply -n sb-ingress-nginx -f truststore.yaml

    • Deploy the helm chart with helm upgrade --install sb-nginx -n sb-ingress-nginx -f values .

  2. Use helm to deploy SmartBridge:

    • Navigate to the SmartBridge folder under helm/smartbridge

    • Create the namespace for SmartBridge with kubectl create namespace smartbridge

    • Create the secrets in Kubernetes SmartBridge needs [Process / Script TBD]

    • Create the configmap (via helm values file) SmartBridge needs [Process / Script TBD]

    • Deploy the helm chart with helm upgrade --install smartbridge -n smartbridge -f values/values_YOUR-UNIQUE-NAME.yaml .

A note about 3rd party dependency upgrades:​

Over the coming months, these components will be upgraded as follows:

  • minio will upgrade to quay.io/minio/minio:RELEASE.2023-04-28T18-11-17Z
  • minio-client will upgrade to quay.io/minio/mc:RELEASE.2023-04-12T02-21-51Z
  • hub.docker.com/stakatar/reloader will upgrade to hub.docker.com/stakater/reloader:v1.0.24
  • hub.docker.com/redis:6.2.1-alpine will upgrade to redis:6.2, then 7-alpine